Express Mail Label No.^H4468337US 
Date Mailed: November 1^^001 



10002723 . 1116131 



UNITED STATES PATENT APPLICATION 
FOR GRANT OF LETTERS PATENT 



Vibhor Julka 
Sanjeevan Sivalingham 
Roger Gustavsson 

INVENTORS 



MOBILITY MANAGEMENT ENTITY 
FOR HIGH DATA RATE WIRELESS 
COMMUNICATION NETWORKS 



COATS & BENNETT, P.L.L.C. 

P.O. Box 5 
Raleigh, NC 27602 
(919) 854-1844 





MOBILITY MANAGEMENT ENTITY FOR HIGH DATA RATE WIRELESS 
COMMUNICATION NETWORKS 



RELATED APPLICATIONS 



[0001] This application claims priority benefit under 35 U.S.C. 1 1 9(e) from the United 
States provisional application Serial No. 60/297,908, filed on June 13, 2001, and entitled 
"A Method for Time-Stamp Based Replay-Protection and PDSN Synchronization at the 
PCF," which is incorporated in its entirety by reference herein. 



[0002] The present invention generally relates to high data rate wireless 
communication networks, and particularly relates to mobility management in data-only 
networks, such as in Tl A/El A/I S-856 based networks. 

[0003] Advanced high data rate wireless communication networks offer subscribers 
the range of applications and convenience available only with relatively high bandwidth 
communication between the subscribers' access terminals and the wireless access 
network. One approach to achieving higher bandwidth involves the use of data-only 
access networks, with first generation evolution, data-only (1 xEVDO) networks 
representing an example of this approach. 

[0004] 1 xEVDO networks generally follow the TIA/EI A/IS-856 interim standard, 
which specifies a framework for high data rate (HDR) packet data communication 
between a public data network (PDN), such as the Internet, and subscribers' access 
terminals. IxEVDO networks forego the use of a mobile switching center (MSC), 
instead of using a packet control function (PCF) to route subscriber data between a 
packet data serving node (PDSN) interfaced to a PDN and an access network controller 
(ANC) supporting the subscribers' access terminals. 



BACKGROUND OF THE INVENTION 



1 




[0005] Each ANC manages the radio resources for one or more access network 
transceiver systems (ANTS), which provide the actual radio resources for radio 
frequency control and data signaling between the wireless access terminals and the 
network. Typically, the ANCs are arranged in subnets, with one or more ANCs per 
subnet. The PCF supports access terminal connections across multiple subnets and is 
responsible for routing data to the appropriate ANC within an access terminal's current 
subnet. 

[0006] Mobility management, that is, tracking movement of access terminals 
between ANCs and between subnets, is complicated by the nature of packet data 
communications. Many types of packet data sessions, such as web browsing, involve 
intermittent activity with relatively long periods of dormancy. For example, an access 
terminal may establish a connection to the network through a given ANC within a given 
subnet and then, while dormant, move to the service area of another ANC, either in the 
same subnet, or possibly within a different subnet. 

[0007] This type of dormant handoff poses challenges in managing the mobility of an 
access terminal that has an open connection with the network but moves between ANCs 
and subnets within the network during periods of dormancy. Ideally, an approach to 
mobility management within the network would minimize network control traffic 
overhead, require only minimal changes at the PCF and ANC to maintain compatibility 
with current implementations of those entities, and provide flexibility in defining the size 
of subnets within the network. 



[0008] The present invention comprises methods and apparatus for access terminal 
(AT) mobility management in a high data rate packet network, such as a wireless 
communication network configured in accordance with the TIA/EIA/IS-856 standard. A 
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logical entity referred to herein as a "session controller" facilitates access terminal (AT) 
mobility management at the subnet granularity, thereby reducing the amount of network 
communication and processing overhead associated with AT mobility management, 
particularly at the packet control function (PCF). 

[0009] A SC provides AT mobility management within its corresponding subnet, 
where each subnet comprises one or more access network controllers (ANCs). The SC 
tracks movement of dormant ATs between ANCs in its subnet, and can cooperate with 
other SCs to support mobility management across subnets. This arrangement 
eliminates the need to involve the PCF in the handoff of dormant ATs between ANCs 
within the same subnet, and allows a single subnet to span multiple ANCs. 
[0010] In supporting mobility management within IxEVDO networks, the SC 
preferably provides one or more of the following mobility management functions: Unicast 
Access Terminal Identifier (UATI) assignment, AT session information maintenance; 
selected air interface protocol support; and A13/A14 message support associated with 
mobility management. In at least one embodiment, the use of independent routing tags 
in the SC and the PCF supports at least some of the above functionality. 
[0011] When an AT establishes or reestablishes an active connection with the 
network, the PCF and SC store routing tags identifying the ANC through which that 
connection is established. The SC additionally stores session information for the 
connection. Subsequently, the AT may go dormant, although the Point-to-Point (PPP) 
connection between the PDSN and the AT is maintained. As the dormant AT moves 
between ANCs within a given subnet, the corresponding SC updates its routing tag to 
reflect this movement. Further, the SC provides session information associated with the 
AT to the receiving ANC, and causes the ANC that was supporting the AT to clear its 
session information for the AT. 
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[0012] These SC functions allow the network to successfully reinitiate packet 
delivery to the AT, even if the PCF-based routing tag is outdated. That is, the PCF 
directs a sen/ice request to the ANC pointed to by its routing tag. If the AT has moved 
from this ANC, the ANC forwards the service request to the SC, which in turn contacts 
the ANC pointed to by its routing tag. In response, the SC-selected ANC pages the AT 
and sets up the required connections with the PCF, which action causes the PCF to 
update its routing tag. 

[0013] In other instances, for example, where a dormant AT moves across subnets, 
both the PCF and the SC might track this change and update the routing tag and .other 
information appropriately. The SC in the receiving subnet might cooperate with the SC 
in the first subnet in terms of tracking this movement and updating the associated 
information. Other SC-to-SC communication might arise when a given SC queries other 
SCs regarding the current location of an AT, for example. 



[0014] Fig. 1 is a diagram of an exemplary wireless communication network, 
including the session controller entity of the present invention. 

Fig. 2 is a simplified version of the network of Fig. 1 and illustrates the use of 
PCF and SC routing tags. 

Fig. 3 is a call flow diagram of an access terminal establishing a network 
connection. 

Fig. 4 is a call flow diagram of network-initiated call re-activation where the PCF 
routing tag is current. 

Fig. 5 is a call flow diagram of network-initiated call re-activation where the PCF 
routing tag is out of date. 
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Fig. 6 is a call flow diagram where the SC routing tag is out of date and the PCF 



sends a service request to all of its associated ANCs. 

Fig. 7 is a call flow diagram of intra access network handoff of a dormant access 
terminal with no subnet change. 

Fig. 8 is a call flow diagram of intra-SC access network handoff of a dormant 
access terminal with a subnet change. 

Fig. 9 is a call flow diagram of intra-PCF, inter-SC and access network handoff of 
a dormant access terminal with a subnet change. 

Fig. 10 is a call flow diagram of inter-SC/inter-PCF handoff. 



[0015] While the following discussion bases its exemplary details on a IxEVDO 
wireless communication network configured in accordance with the TIA/EIA/IS-856 
standard, it should be understood that the techniques for mobility management 
described herein have applicability beyond these specific network types. Thus, the 
present invention may find utility in IxEVDO networks, in other types of existing 
networks, and in forthcoming networks based on yet to be developed standards. 
[0016] Turning now to the drawings, Fig. 1 is a diagram of a wireless communication 
network generally referred to by the numeral 10. The exemplary network 10 comprises 
a PCF 12 coupled to one or more PDSNs 14 through an IP network 16, which PDSNs 14 
in turn couple the network 10 to one or more PDNs 18 and 20 (e.g., the Internet or other 
packet data networks). The network 10 further comprises a plurality of access network 
controllers (ANCs) 22 (sometimes referred to as base station controllers or BSCs), with 
each ANC 22 providing control and call processing support to one or more ANTS 24 
(sometimes referred to as radio base stations or RBSs). It should be noted that Fig. 1 is 
an exemplary logical diagram; the physical implementation of the network 10 may differ. 
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[0017] Each ANTS 24 provides radio coverage for a given area. The ATs 28 

connect to the network 10 through wireless communication with the ANTS 24, which 

contain the necessary radio resources. The network 10 also comprises an 

authentication, authorization, and accounting (AAA) entity 30 involved in authorizing and 

accounting for such access, and one or more session controllers (SCs) 32, which in the 

practice of the present invention, facilitate mobility management of the ATs 28 within the 

network 10. 

[0018] One or more ANTS 24 may be grouped into a subnet 26. The illustrated 
network comprises two subnets (26-1 and 26-2), but an actual implementation may have 
a lesser or greater number of subnets 26, and may have a lesser or greater number of 
ANTS 24 within each subnet. 

[0019] In operation, packet data flows between the ATs 28 and the PDN 1 8 or 20 via 
the network 10. In facilitating this data flow, the network 10 routes packet data to and 
from the individual ATs 28 based on routing information identifying the correct ANC 22 
for each AT 28. In this context, "correct" simply denotes the ANC 22 currently 
supporting the connection with a given AT 28. In the case of data delivery to a dormant 
AT 38, the PCF 12 receives packet data from the PDN 1 8, for example, through one of 
the PDSNs 14, and uses its routing tag information to identify the ANC 22 to which it 
should forward the data. Once the data reaches the correct ANC 22 that ANC 22 
determines to which ANTS 24 the data should be routed for radio transmission to the AT 
28 in question. 

[0020] In general, one SC 32 supports one subnet 26, which may comprise one or 
more ANCs 22, with each ANC 22 supporting a number of ANTS 24. The present 
invention defines an A14 signaling interface for communication between the SC 32 and 
the ANCs 22 within the corresponding subnet 26. This signaling interface permits 
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transfer of session related information between the ANCs 22 and the SC 32, thus 
facilitating mobility management operations. 

Exemplary messages include the following items: 

o A14 Unicast Access Terminal Identifier (UATI) Assignment 
Request/Response 

o A14 Session Information Update Request/Response 

o A1 4 SC Service Request/Response 

o A1 4 Connection Setup Request/Response 

o A14 Session Info Cancel Request/Response 
The above messages and the associated functions or network operations associated 
with their use are explained more fully below. Also, note that inter-ANC signaling for 
facilitating efficient inter-ANC handoff of dormant ATs 28 might be supported via A13 
signaling between the involved ANCs 22. 

[0021] In at least one embodiment of the present invention, mobility management is 
distributed between ANCs 22, SCs 32, and PCFs 12. In particular, a given ANC 22 is 
responsible for AT location management down to the granularity of a single ANTS 24 
under control of the ANC 22. This implies that the ANC 22 is responsible for paging ATs 
28 supported by ANTS 24 under its control (i.e., within the "domain" of the ANC 22). 
Limiting required ANC-based paging in support of network initiated packet delivery to a 
dormant AT 28 allows for efficient paging operations within the context of the present 
invention. A given SC 32 is responsible for location management across ANCs 22 within 
a given subnet 26, and, in some instances, across subnets 26. Providing intra-subnet 
mobility management for dormant ATs 28 via the SC 32 eliminates the need to involve 
the PCF 12 in intra-subnet handoff s of dormant ATs 28. 

[0022] It should be understood that SCs 32 could be co-located with an ANC 22, or 
co-located with the PCF 12. In the first case, co-location with an ANC 22 limits the 
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footprint of the SC 32 to the coverage area of the ANC 22 with which it is co-located. 
While this might be desirable in certain network arrangements, it does miss the 
opportunity to use a given SC 32 to manage AT mobility across two or more ANCs 22 
within or across subnets 26. In the second case, co-location of the SC 32 with PCF 12 
may be desirable in certain network arrangements, but does not necessarily relieve the 
PCF-related communication links from mobility management traffic associated with the 
SCs functionality. 

[0023] In an exemplary approach, SCs 32 are at least logically maintained 
separately from ANCs 22 and PCFs 12, such that one SC 32 may provide mobility 
management for multiple ANCs 22, and further such that mobility management traffic 
between ANCs 22 and SCs 32 does not burden the communication links (A interfaces) 
to the PCF 12. 

[0024] In this context, paging efficiency and reduction of overall PCF-involved 
signaling derives from the use and management of SC-based and PCF-based routing 
tags. Fig. 2 presents a simplified illustration of the network 10, focusing on the PCF 12, 
ANCs 22, and SCs 32, and further depicts routing tags 40 and 42 located in the PCF 12 
and SCs 32, respectively. The PCF 12 maintains a routing tag 40 (TAG PC f) for each AT 
28 having a connection supported by the PCF 12. Each TAG PC f has a corresponding 
tag array 42 (TAGsc) maintained by the SC 32 for that AT 28. The following discussion 
focuses on operations involving one TAG PC f and the corresponding tag array TAG S c for 
a given AT 28. It should be understood that the PCF 12 and SC 32 would apply the 
same management logic to multiple sets of routing tags 40 and 42 associated with a 
plurality of ATs 28. 

[0025] In general, the PCF 12 updates TAG PC f each time it receives a service 
request (e.g., an A9 Setup A8 message) for an AT 28 from one of the ANCs 22 
supported by the PCF 12. That is, the PCF 12 causes TAG PCF to "point" to the last ANC 
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22 that requested service for the AT 28. This setting of TAG PC f may be accomplished by 
setting TAG PC f to an identification value corresponding to one of the ANCs 22 supported 
by the PCF 12. For example, assume that the PCF 12 supports N ANCs 22 arranged as 
one or more subnets 26. These N ANCs 22 might be identified by ANCJDs (1 N) 
where there are N such ANCs 22. Thus, ANCIDs in this scenario would be ANC1 , 
ANC2, ANC3, ... , ANC A/. 

[0026] A subset Kof these N ANCs 22 might correspond to a given subnet 26. 
Thus, the SC 32 associated with that subnet 26 might maintain the corresponding TAGsc 
as an array of ANCJD values (1 .. K). That is, the SC 32 maintains TAG S c as an array 
of pointers {AN^ AN 2 , ... , AN h ... , AN K }. Each array entry points to one of /CANCs 22. 
Generally, the SC 32 maintains the entries in TAGsc based on movement of the AT 28 
within and between subnets 26. Thus, the SC maintains routing information that 
indicates which of the ANCs 22 is currently identified with the AT 28. 
[0027] The array TAG S c is a set of pointers to the ANCs 22 supported by the SC 32. 
Setting an array entry to one (1) indicates that the ANC 22 corresponding to that array 
entry has session information for the AT 28. Conversely, clearing an entry in TAG S c 
indicates that the corresponding ANC 22 does not have session information for the AT 
28. Thus, TAGsc may be initialized by setting all elements to zero (i.e., AN| = 0 for all i = 
1 .. K). Then, in mobility management operations, the SC 32 may set (1) or clear' (0) 
each element of the tag array based on A14 signaling messages received from or sent 
to the ANCs 22. For example, the SC 32 sets ANi of TAG SC to one (1 ) if the SC 32 
receives an A14 Session Information Update message from ANCi; sends an A14 
Session Information Update message to ANCi; or sends an A14 Session Information 
Response message to ANCi. In contrast, the SC 32 clears ANi of TAG S c if the SC 32 
receives an A14 Session Information Cancel Request message from ANCi or if the SC 
32 sends an A14 Session Information Cancel Request message to ANCi. 
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[0028] For example, assume that the SC 32 supports three ANCs 22, denoted as 

ANC1 , ANC2, and ANC3. Further, assume that the SC 32 receives a Session 

Information Cancel Request message from ANC1 . The SC 32 first sets AN1 in TAGsc to 

zero. It then checks whether any other ANC 22 operating under its control has session 

information for the AT 28 (i.e., is at least one of AN2 and AN3 in TAGsc non-zero?). If 

not, this condition might indicate that the SC 32 has lost track of the AT 28. If so, it 

sends an A14 Session Information Update message to all ANCs 22 (ANC1 , ANC2, and 

ANC3). In response, these ANCs page the AT 28. 

[0029] Each ANC 22 (i.e., ANC1 , ANC2, and ANC3) receiving the Session 
Information Update message attempts to page the AT 28, but only one of them will 
receive a page response. Those ANCs not receiving a page response from the AT 28 
will send A14 Session Information Cancel Request messages to the SC 32, which in turn 
will clear the corresponding entries in TAGsc- Thus, this procedure allows the SC 32 to 
"find" the AT 28 and appropriately clear and set entries in TAGsc to reflect the current 
location of the AT 28. 

[0030] When an ANC 22 receives a Route Update or other communication from an 
AT 28 for which it has no session information, the ANC 22 queries the SC 32 for session 
information by sending an A14 Session Information Update Message. When the SC 32 
receives such a request from ANCi, it returns the needed session information to ANCi in 
the form of an A14 Session Information Update Response message. Typically, session 
information contains the following pieces of information (if applicable): air interface 
protocol attributes and associated public data (the format of this information is specified 
in Tl A/El A/I S-856 standards); PDSN address (e.g., IP v4 address); Mobile Identity 
(MNJD); Access Network Identifiers (PANID/CANID). 
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[0031] Further, since this request indicates that the AT 28 is located at the 
requesting ANC (ANCi), the SC 32 sets TAG SC to point to ANCi. The SC 32 also checks 
to see if TAGsc indicates any other ANCs 22 have session information for the AT 28 
(i.e., are any ANj * 0 in TAGsc. where j * j?). For any such entries (i.e., ANj * 0 and 
where j * i), the SC 32 sends an A14 Session Information Cancel message to the 
corresponding ANC(s) 22, and clears ANj. 

[0032] In general, the range of mobility management scenarios includes at least 
initial connection establishment, intra- and inter-subnet dormant handoff, and connection 
reestablishment (reactivation of a dormant AT 28). The functionality associated with 
operations in these general scenarios may be better understood in the context of SC- 
based mobility management operations. 

[0033] To that end, an exemplary set of call flow diagrams follows, illustrating 
exemplary functionality for selected operations. In supporting these and other 
operations, it should be understood that the SCs 32 generally comprise one or more 
processors or processing systems 33 having supporting memory 35. In actual 
implementation, memory 35 may comprise several types of memory, including but not 
limited to volatile working memory for program execution, non-volatile memory for 
configuration data and parameter storage, and disk storage for database and operating 
program storage. Similarly, it should be understood that ANCs 22, PCFs 12, PDSNs 14, 
and other network entities each comprise processing and communication resources. 
[0034] The exemplary call flow diagrams begin with Fig. 3, which diagrams the call 
flow of an AT 28 originating a IxEVDO connection with the network 10. This connection 
allows data transfer between the PDN 18 and the AT 28. One may refer to Fig. T for 
identification of the interface nomenclature used in the following discussion (e.g., A8/A9, 
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A10/A1 1 , A14 interfaces). Establishing the connection between the AT 28 and the 
network 10 includes the following steps: 

a. The AT 28 and a given one of the ANCs 22 perform IS-856 Unicast Access 

Terminal Identifier (UATI) Assignment procedures. Upon receipt of the 
UATI Assignment message the ANC 22 sends an A14 UATI Assignment 
Request message to the SC 32. The SC 32 performs UATI assignment 
and sends an A14 UATI Assignment Response message to the ANC 22, 
which in turn will send the associated air interface message to the AT 28. 

b. The AT 28 and ANC 22 perform IS-856 session and connection establishment 

(the reader may refer to the Interim Standard document IS-878, Section 
2.1.1). 

c. The AT 28 and the ANC 22 initiate Point-to-Point Protocol (PPP) and Link 

Control Protocol (LCP) negotiations for access authentication, which may 
be done in accordance with the Request for Comments (RFC) 1661 
covering PPP. 

d. The ANC 22 generates a random challenge and sends it to the AT 28 in a 

Challenge Handshake Authentication Protocol (CHAP) Challenge packet 
in accordance with the Request for Comments (RFC) 1994. 

e. When the ANC 22 receives the CHAP response packet from the AT 28, the 

ANC 22 and the access network AAA 30 exchange RADIUS messages 
per A12 Access Authentication procedures. The Access-Accept contains 
a RADIUS attribute with Type set to 20 (Callback Id), Length set to 15, 
and the String field set to the 15 digit mobile number (MN) ID. One may 
refer to the Request for Comments (RFC) 2865 for details regarding 
RADIUS. 
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f. The ANC 22 returns an indication of CHAP authentication success to the AT 

28. 

g. The ANC 22 sends session related information (including the assigned UATI, 

MNJD, previous/current access network identifiers (PANID/CANID) if 
applicable and available) to the SC 32 via the A14 Session Info Update 
Request-Response messages. This step can occur anytime after the 
ANC 22 receives an Access-Accept packet from the AN-AAA. The SC 32 
will set TAGsc (i.e., tag 42) to this ANCID as where the AT 28 is currently 
located. 

h. The AT 28 indicates to the ANC 22 and the PCF 1 2 that it is ready to 

send/receive data (e.g. this will involve the exchange of 
XonRequest/XonResponse messages to request transition to the Open 
State (service stream)). 

i. The PCF 12 and the PDSN 14 perform A10/A11 Connection establishment as 

per TIA/EIA/IS-2001-A, Section 2.15. 

j. The ANC 22 sends updated session related information (in this scenario the 
PDSN Address associated with the A10 connection) to the SC 32 via the 
A14 Session Info Update Request/Response messages. This step can 
occur anytime after the ANC 22 initiates A8/A9 procedures. This 
procedure can also be executed whenever session information at the 
ANC 22 is changed (e.g. upon updating of the authentication keys, re- 
negotiation of IS-856 protocols). 

k. The PDSN 14 and the AT 28 establish the link layer (PPP) connection and 

then perform (mobile Internet protocol) MIP registration procedures over 
the PPP connection per TIA/EIA/IS-835-A. 
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i. After completion of the MIP registration, the connection is established and 
packet data can flow between the AT 28 and the PDSN 14. 
[0035] Fig. 4 illustrates re-establishing an active connection with a dormant AT 28. 
Here, the AT 28 has a dormant PPP connection with a PDSN 14, but is not engaged in 
data transfer with the network 10. This scenario assumes the presence of at least ANC1 
and ANC2, and that the AT 28 last established an active connection with the network 10 
through ANC1 , and that the AT 28 has not moved from the coverage area of ANC1 . 
Because ANC1 was last used to service the AT 28, TAG PC f points to ANC1 , and the 
corresponding entry "AN1" in the array TAG S c in the SC 32 is set to "1 ," indicating that 
ANC1 has session information for the AT 28. 

[0036] New packet data intended for the dormant AT 28 arriving at the PDSN 1 4 
initiates reactivation of the connection with the AT 28. Re-establishing connection with 
the AT 28 comprises the following steps: 

a. The PDSN 1 4 sends data packets for an AT 28 on an existing A1 0 
connection. 

b. The PCF executes A9 base station (BS) Service Request/Response 
procedures with the ANC 22 specified by TAG PC f (tag 40), which points to 
ANC1 . Upon receipt of the A9-BS Service Response message, the PCF 
12 starts the timer T net _conn. 

c. In this scenario, TAG PC f points to the correct ANC 22. ANC1 has session 
information for the AT 28 in question, and ANC1 sends a page message 
to the AT 28 over the control channel. 

d. The AT 28 and ANC1 establish a radio connection per IS-856. 

e. ANC1 and the PCF 12 perform A8/A9 connection establishment. For 
consistency, the PCF 12 might reset TAG PC f to point to ANC1 , although it 
could leave TAG PC f unchanged since it already points to ANC1 . Upon 
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receipt of the A9-Setup-A8 message, the PCF 12 stops the T NE t_conn 

timer used to time the connection setup responsive to the service 

request/response exchange, 
f. After the radio link and the A8 connection have been established, data 

can be exchanged between the AT 28 and the PDSN 14 via the restored 

active data connection. 
[0037] Fig. 5 illustrates an approach to network-initiated call re-activation where the 
PCF 12 does not have up-to-date routing tag information, perhaps because the AT 28 
has undergone a dormant mobile handoff between ANCs 22 within the same subnet 26. 
Here, the scenario assumes that ANC1 supported the last active connection with the AT 
28. Thus, TAG pcf in the PCF 12 points to ANC1 , which is out-of-date owing to the 
dormant handoff of the AT 28 from ANC1 to ANC2. 

[0038] When the dormant AT 28 was handed off from ANC1 to ANC2, it sent a 
Route Update message to ANC2. ANC2, recognizing that it had no session information 
for the AT 28, queried the SC 32 using the A14 signaling messages Session Information 
Update Request/Response. 

[0039] This action caused the SC 32 to update the array entries for ANC1 and 
ANC2 in TAGsc, and provide ANC2 with the requested session information. Further, the 
SC 32 prompted ANC1 to kill or otherwise clear its session information for the AT 28, 
since it was handing off control of the AT 28 to ANC2. Clearing session information in 
this manner prevents ANCs 22 from retaining information for ATs 28 no longer in their 
coverage area. 

[0040] Thus, the scenario is that the PCF 12 incorrectly identifies ANC1 with the AT 
28, while the SC 32 correctly identifies ANC2 with the AT 28. ANC1 , receiving a service 
request from the PCF 12, essentially redirects this service request to the SC 32, so that 
SC 32 can notify ANC2 that the PCF 12 desires communication with AT 28. Upon this 
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service request redirection via the SC 32, ANC2 can establish a connection between the 
AT 28 and the PCF12. 

[0041] Re-activation is made efficient in the above scenario by virtue of the mobility 
management functions of the SC 32, and comprises the following steps: 

a. The PDSN 14 sends data packets for the AT 28 on an existing A10 
connection (the dormant connection). 

b. The PCF 12 executes A9 BS Service Request/Response procedures with 
the ANC 22 pointed to by TAG PC f (ANC1). ANC1 no longer has session 
information for the AT 28 because the SC 32 caused ANC1 to clear such 
session information in response to the dormant AT moving into the 
coverage area of another ANC 22 (ANC2). In other words, a dormant 
handoff has caused TAG PC f to become outdated. 

c. In response to receiving a service request from the PCF 12 for the AT 28, 
ANC1 , recognizing that it no longer has relevant session information, 
initiates A14 SC Service Request/Response procedures with the SC 32. 

d. Upon receipt of the A14 SC Service Request message from the PCF- 
selected ANC 22, the SC 32 determines which ANC 22 has control of the 
dormant AT 28, and sends an A14 SC Connection Setup message to that 
ANC (i.e., ANC2). The SC 32 identifies the correct ANC 22 by use of its 
routing tag 42, TAG S c- 

e. ANC1 sends an A9-BS Service Response to the PCF 12. This step can 
occur anytime after receipt of the A9-BS Service Request message. 
Upon receipt of this service request, the PCF 12 starts the connection 
setup timer T N et_conn- 

f . ANC2 then sends a paging message to the AT 28 over the control 
channel. 
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g. ANC2 and the AT 28 establish a radio connection per IS-856. 

h. ANC2 and the PCF 12 then establish A8/A9 connections. This causes 
the PCF 12 to update its TAG PCF to point to ANC2. Upon receipt of the 
A9-Setup-A8 message, the PCF 12 stops timer Tnetjdonn- Note that the 
PCF 12 might use expiration of the timer to determine whether to abort or 
retry connection reestablishment. 

i. After the radio link and the A8 connection are reestablished, data may be 
exchanged between the reactivated AT 28 and the PDSN 14. 

[0042] Fig. 6 illustrates exemplary call flow details where TAG S c in the SC 32 does 
not point to the correct ANC 22 (i.e., does not point to the ANC 22 currently supporting 
the dormant AT 28). This scenario might arise where the AT 28 crossed ANC 
boundaries and did not send a Route Update message or that message was lost. The 
scenario further assumes that the PCF's router tag 40, TAG PC f, also is outdated. Thus, 
in this instance, neither the PCF 12 nor the SC 32 has up-to-date routing pointers' for the 
AT 28. 

[0043] Connection reactivation in this scenario comprises the following steps: 

a. PDSN 1 4 sends data packets for a dormant AT 28 to the PCF 1 2 via an 
existing A10 connection. 

b. The PCF 12 executes A9 BS Service Request/Response procedures with 
the ANC 22 pointed to by TAG PCF (i.e., ANC1). 

c. ANC1 pages the AT 28 in response to receiving the A9 Service Request 
message from the PCF 22. Because the SC 32 did not receive notice of 
the AT 28 moving from ANC1 , it failed to clear session information from 
ANC1 . Therefore, ANC1 still has session information for the dormant AT 
28 and issues a page. ANC1 also starts a paging timer to detect paging 
failures. 
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When the paging timer expires, ANC1 infers that the AT 28 is no longer in 
its coverage area and deletes the session information stored for the AT 
28. It also sends an A14 Session Info Cancel message to the SC 32. 
Upon receipt of that Session Info Cancel message, the SC 32 determines 
which ANC 22 has control of the AT 28 by examining its array TAGsc- If 
the SC 32 cannot determine which ANC 22 is supporting the AT 28, it 
sends session information for all ANCs 22 supported by it. In the 
illustrated scenario, the SC 32 sends session information to all ANCs 22 it 
supports (here, ANC1 and ANC2) by executing A14 Session Information 
Update procedures with them, such as by the exchange of A14 Session 
Information Update Request/Response messages. This sets the 
corresponding entries in TAG S c for both ANC1 and ANC2. 
In failing to receive an A9-Setup-A8 message from any ANC 22 before 
expiration of T NE t_conn, the PCF 12 re-sends the A9-BS Service Request 
message to all ANCs 22 that it supports, in an attempt to establish A8/A9 
connections with the ANC 22 currently supporting the AT 28. ANCs 1 
and 2 receive this new service request and send paging messages over 
the control channel in an attempt to contact the AT 28. 
ANC2 and the AT 28 establish a radio connection per IS-856. 
When the paging timer at ANC1 expires without a response from the AT 
28, ANC1 deletes its session information for AT 28, and sends an A14 
Session Information Cancel message to the SC 32. In response, the SC 
32 clears the corresponding ANi entry in TAGsc, leaving the only set 
pointer in TAG S c the one corresponding to ANC2. 
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i. ANC2 and the PCF 12 establish A8/A9 connections, which causes the 
PCF 1 2 to update its TAG PC f to point to ANC 2. The routing tags 40 and 
42 in the PCF 12 and SC 32, respectively, are now updated, 
j. After the radio link and the A8 connection are reestablished, data may be 
exchanged between the reactivated AT 28 and the PDSN 14. 
[0044] Fig. 7 illustrates one of several scenarios where the SC 32 eliminates the 
need to involve the PCF 12 in mobility management signaling. As the dormant AT 28 
moves from ANC 2 to ANC1 , it generates a Route Update message that may be used to 
keep route pointers in TAGsc current, without the need for updating TAG PC f- This 
minimizes traffic and processing overhead that would otherwise be incurred by the PCF 
12 and its network interfaces if intra-subnet handoffs required PCF routing tag updating, 
which would be the case in the absence of the SC 32. 
[0045] The illustrated call flow includes the following steps: 

a. ANC1 receives a Route Update from the AT 28 after the AT 28 crosses 
the coverage boundary between ANC 2 and ANC1 . That is, ANC1 is 
receiving the AT 28 from ANC 2. 

b. ANC1 sends an A14 Session Info Update Request to the SC 32 to obtain 



session information via the A14 Session Info Update Response message. 
The SC 32 updates its TAG SC to reflect the handoff from ANC 2 to ANC1 . 
c. The SC 32 initiates A14 Session Information cancellation procedures (via 
A14 Session Info Cancel Request/Response messages) with ANC 2. 
Cancellation of session information for the AT 28 in ANC 2 prevents 
retention of session information. Without such cancellation, errors might 
arise if the PCF 12 later attempts to reactivate the call with the AT 28. In 
that scenario, the routing tag 40 in the PCF 12 would still point to ANC 2 



session information for the AT 28. The SC 32 returns the requested 
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(the source ANC), but the AT 28 would have moved to ANC1 (the target 



ANC). If source ANC still had session information for the AT 28, it would 



not immediately forward the PCPs service request to the SC 32, as it 



should. 



[0046] Fig. 8 illustrates an intra-PCF/intra-SC handoff where the AT 28 changes 
subnets 26. This scenario assumes that ANC 2 and ANC1 are in different subnets 26, 
and that the AT 28 moves from ANC2 to ANC1 . With a subnet change the AT 28 sends 
a request for a new UATI to the target ANC. 
[0047] Call processing includes the following steps: 

a. The AT 28 and ANC1 (target ANC) perform IS-856 UATI Assignment 
Procedures in response to the AT crossing into ANCVs coverage area. 
Upon receipt of the UATI Assignment message ANC1 sends an A14 
UATI Assignment Request message to the controlling SC 32. The 
controlling SC 32 determines that a session exists with the associated 
UATI and sends an A14 UATI Assignment Response message to ANC1, 
which in turn will send the associated air interface message to the AT 28. 

b. The SC 32 has stored session information associated with the UATI and it 
sends this information to ANC1 via A14 signaling procedures (A14 
Session Info Update Request/Response messages). The SC 32 will 
update the TAGsc to reflect the change from ANC2 to ANC1 . 

c. The SC 32 initiates A14 Session Information Cancellation procedures (via 
A14 Session Info Cancel Request/Response messages) with ANC2 (the 
source ANC 22). The SC 32 knows the source ANCID based on the 
previous TAGsc (i.e- prior to update in step b). 

[0048] Fig. 9 illustrates exemplary call flow for an intra-PCF/inter-SC dormant 
handoff of an AT 28, where different SCs 32 are used to manage the involved subnets. 
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In this scenario, the source SC 32 (SC2) may be used to provide session information to 
the target SC 32 (SC1). Here, "source" refers to the SC 32 managing the subnet 26 
from which the AT 28 is being handed off from, and "target" refers to the SC 32 
managing the subnet 26 receiving the AT 28. Thus, the involved SCs 32 support such 
movement by sharing or transferring session information for the AT 28. 
[0049] Several approaches are available for coordinating communication between 
SCs 32. For example, a SC 32 might query neighboring SCs 32 for needed session 
information based on which SCs 32 are associated with the neighboring or closest 
subnets, for example. In any case, exemplary call flow includes the following steps: 

a. The AT 28 and target ANC 22 (ANC1) perform IS-856 UATI Assignment 
Procedures (the AT 28 crosses a subnet boundary). Upon receipt of the 
UATI Assignment message, ANC1 sends an A14 UATI Assignment 
Request message to the target SC 32 (SC1). 

b. In this scenario, SC1 does not have the stored session information 
associated with the UATI and sends a request to the source SC 32 (SC2) 
to obtain session information for the AT 28 in questions using A13^ 
signaling procedures for inter-SC communication. SC2 returns the 
requested session information to SC1 . 

c. SC1 then sends an A14 UATI Assignment Response message to ANC1 , 
which in turn sends the associated air interface message to the AT 28. 

d. SC1 then sends the session information received over the A13 interface 
to ANC1 via A14 signaling procedures (A14 Session Info Update 
Request/Response messages). SC1 also updates its TAG S c so track 
movement of the AT 28 into the coverage area of ANC1 . 
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e. SC2 initiates A14 Session Information cancellation procedures (via A14 
Session Info Cancel Request/Response messages) with ANC2. SC2 
also clears the array entry for ANC2 in its array TAG S c. 
[0050] Fig. 10 illustrates exemplary call flow for an inter-PCF/inter-SC dormant 
handoff of an AT 28, where different SCs 32 belonging to different PCFs 12 are used to 
manage the involved subnets 26. In this scenario, the source SC 32 (SC2) may be used 
to provide session information to the target SC 32 (SC1). Here, "source" refers to the 
SC 32 managing the subnet 26 from which the AT 28 is being handed off from, and 
"target" refers to the SC 32 managing the subnet 26 receiving the AT 28. Thus, the 
involved SCs 32 support such movement by sharing or transferring session information 
for the AT 28. 

[0051] Several approaches are available for coordinating communication between 
SCs 32. For example, a SC 32 might query neighboring SCs 32 for needed session 
information based on which SCs 32 are associated with the neighboring or closest 
subnets 26, for example. In any case, exemplary call flow includes the following steps: 

a. The AT 28 and target ANC 22 (ANC1) perform IS-856 UATI Assignment 
Procedures (the AT 28 crosses a subnet boundary). Upon receipt of the 
UATI Assignment message, ANC1 sends an A14 UATI Assignment 
Request message to the target SC 32 (SC1). 

b. In this scenario, SC1 does not have the stored session information 
associated with the UATI and sends a request to the source SC 32 (SC2) 
to obtain session information for the AT 28 in questions using A13 
signaling procedures for inter-SC communication. SC2 returns the 
requested session information to SC1 . 

c. SC1 then sends an A14 UATI Assignment Response message to ANC1 , 
which in turn sends the associated air interface message to the AT 28. 
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d. SC1 then sends the session information received over the A13 interface 
to ANC1 via A14 signaling procedures (A14 Session Info Update 
Request/Response messages). SC1 also updates its TAGsc so track 
movement of the AT 28 into the coverage area of ANC1 . 

e. SC2 initiates A14 Session Information cancellation procedures (via A14 
Session Info Cancel Request/Response messages) with ANC2. SC2 also 
clears the array entry for ANC2 in its array TAGsc- 

f. ANC1 initiates IS-856 Location Update Procedures with the AT to obtain 
the Previous Access Node ID (PANID) from the AT. ANC1 will compare 
the PANID with the Current Access Node ID (CANID) stored at the ANC. 
If CANID is different than the received PANID, ANC1 and PCF 1 will 
perform A8/A9 connection establishment. ANC 1 will send a A9-Setup-A8 
message to PCF1 with DRI = 0. 

g. Upon receipt of the A9-Set-Up A8 message, PCF1 will set its TAG PC f to 
point to ANC1 . Additionally, PCF1 and the PDSN perform A10/A1 1 
Connection establishment as perT!A/EIA/IS-2001-A Section 2.15. In this 
scenario, the PDSN has no data to send to the AT and indicate this status 
to the PCF1 . 

h. PCF1 initiates A8 release procedures and sends an A9 Release A8 
message to ANC1 . 

i. PDSN and PCF2 initiate A10 connection clearing procedures as per 
T'.A/EIA/IS-2001-A Section 2.15. Upon successful release of the A10 
connection, PCF 2 will clear TAG PC f associated with the AT. 

[0052] In general, the above discussion details exemplary mobility management 
operations of the SC 32 in accordance with the present invention. However, 
implementation and operation of the SC 32 is subject to much variation, and these 
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details should not be construed as limiting the present invention. Indeed, the present 
invention broadly provides for a new logical network entity (the SC 32), which facilitates 
mobility management in IxEVDO wireless communication networks or other types of 
data-oriented wireless communication networks. The SC 32 maintains session 
information supporting AT handoff between ANCs 22, and further maintains routing tags 
(tags 42), which may be updated to track ATs 28 as they move through and across 
subnets 26. With these techniques and features, the SC 32 provides for efficient 
mobility management. Thus, the present invention is limited only by the scope of the 
following claims, and the equivalents thereof. 
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